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DESCRIPTION 
System Overview 

The VAX/VMS Operating System supports all VAX series 
computers, working reliably and efficiently in both time¬ 
sharing and production environments. Time-sharing 
users can work interactively with the system and can 
submit batch jobs. Jobs of all types, including processor 
intensive, I/O intensive, large memory, and real-time, in 
any mix, perform well on VAX/VMS. The system permits 
an absolute limit of 8192 concurrent processes. How¬ 
ever, the actual amount of work supported at one time 
with good performance depends on the types of process¬ 
ing performed as well as on the physical memory and 
secondary storage available. 

System Configuration 

The user receives with VAX/VMS a standard system 
configuration file and a site-independent start-up pro¬ 
cedure. The system manager can modify the site- 
independent start-up procedure or create a site-specific 
start-up procedure. 

To start the system, the system manager performs a 
bootstrap operation. Optionally, the parameter values of 
the selected file can be modified at bootstrap time. The 
system configures itself by executing the start-up proce¬ 
dures. After system start-up, the system manager can 
reset system parameter values on-line for the next boot¬ 
strap operation and can dynamically change a subset of 
the parameter values, i.e., change the configuration of 
the running system. 

To aid the system manager in setting up system parame¬ 
ters, a procedure is provided that analyzes the system 
configuration and generates a file containing parameter 
settings. This file can be modified by the system man¬ 
ager and a system parameter file generated. In addition, 
the system incorporates self-tuning mechanisms. For ex¬ 
ample, the system monitors job performance and in¬ 
creases the amount of physical memory for jobs that 
need it and decreases the amount for jobs that do not. 
However, the system manager is always free to modify 
system parameters to suit special situations or to 
fine-tune. For example, the system manager has the 
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ability to govern the real memory limits for each job. 
Services are provided for monitoring system performance 
and for adjusting system parameters. 

The system manager starts the system from a console 
and a storage device that contains the bootstrap routine. 
After the system starts, the system manager can operate 
the system from any terminal. An automated procedure 
for shutting down the system in an orderly manner (telling 
interactive users to log off, spinning down disks, etc.) is 
provided with the system. 

General Access 

User access to VAX/VMS is by means of a command 
language. The DIGITAL Command Language (DCL), the 
standard command language for VAX/VMS, is supplied 
with the system. DCL commands take the form of a 
command name followed by parameters and qualifiers. 
The commands can be typed on the terminal, included in 
command procedures, and submitted as batch jobs 
(either from the terminal or the card reader). The com¬ 
mands provide basic system services, initiate system 
utility programs, and initiate user programs. 

Many qualifiers exist to provide detailed levels of control 
where needed. However, most qualifiers have default 
values so that the typical command consists only of the 
command name and a few qualifiers. In addition, com¬ 
mand names and keywords can be abbreviated. Another 
facility that saves keystrokes is the ability to substitute 
symbolic names for commands. For example, the user 
might equate a lengthy command to a short symbolic 
name. Thereafter, only the short name need be typed to 
execute the command. 

On erroneous input, the user receives a message. The 
user can obtain on-line documentation by typing HELP 
followed by the name of a command and (optionally) a 
qualifier. The help facility can be used in an interactive 
mode and also is available within many of the interactive 
utility programs. 

In addition to the usual services of an operating system 
in support of program development and operations, 
VAX/VMS provides the following services that enable 
nonprogrammers to process data: 
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• Text processing — The general user requires a few 
days to learn how to use one of the text editors 
supplied with the system. 

• Mail facility — A personal mail facility permits a user 
to send messages to any other user by typing the 
recipient’s name, the subject of the message, and the 
text of the message. If the recipient is logged in, a 
notification that new mail has arrived appears on the 
recipient’s terminal. Otherwise, the recipient is notified 
of the new mail at log-in time. Mail recipients can reply 
to messages and forward them to other users. Mes¬ 
sages can be examined, printed, filed, and edited at 
the terminal. A directory and search capability is incor¬ 
porated to permit rapid scanning of mail files. 
Multi-node operation is available if DECnet-VAX is 
installed. 

• Phone facility — An interactive communication utility 
with networking capability (optional DECnet-VAX 

license is required for multi-node operation). 

• Disk I/O — The general user can create and process 
sequential character files with a few simple DCL com¬ 
mands. Processing includes editing, expanding, copy¬ 
ing, sorting, merging, and deleting files. 

• Command-level programming — The general user 
can create special files called command procedures, 
that contain a series of DCL commands. When a user 
invokes a command procedure, the system processes 
all the commands. Command procedures save many 
keystrokes by permitting the user to catalog series of 
often-entered commands. In addition, the user can 
take advantage of special DCL commands to perform 
programming-type functions such as assigning sym¬ 
bolic names, evaluating numerical and logical expres¬ 
sions, accepting parameters, communicating with the 
interactive user invoking the command procedure, 
performing conditional (IF) and branching (GOTO) 
logic, and error handling conditions. 

VAX/VMS provides a number of line-mode editors, a line¬ 
mode/character-mode editor (EDT), and a character¬ 
mode editor (TPU). 

In character mode (also known as keypad mode), EDT 
permits the user to quickly insert and delete any amount 
of text within the existing text. Some of the capabilities 
are as follows: 

• Position — The user can move a cursor up, down, 
right, left, to the next word, to the preceding word, or 
to the end of the line to be in position for an editing 
operation. 

• Insertions — To insert text, the user simply types the 
characters. 

• Deletions — The user can delete the current charac¬ 
ter or word, the preceding character or word, or blocks 
of text. 

• Cut and paste — The user can move blocks of text 
from one position to another. 


• Searches — The user can search for the next or 
preceding occurrence of a particular string of charac¬ 
ters. 

EDT logs changes and replays them on demand should 
a failure occur during an editing session. 

Finally, the general user has access to any facilities that 
the applications programming user makes available 
through application systems built on top of VAX/VMS. 
Programming users, for example, might construct an 
inventory system that permits general users to query and 
update indexed files that hold the inventory data. 

Program Development 

VAX/VMS provides a comprehensive set of tools for 
developing programs including editors (such as EDT for 
producing and editing source programs), a file differ¬ 
ences utility, programming languages, a linker, a libra¬ 
rian, a symbolic debugger, and a patch utility. The 
assembly-level VAX MACRO language is supplied with 
all systems. Optional high-level languages are listed in 
the VAX/VMS System Software Ordering Table (SPD 
28.98.xx). 

The file differences utility contrasts two files by auto¬ 
matically aligning matching text and optionally ignoring 
comments, empty records, trailing blanks, and multiple 
blanks. Output can consist of a side-by-side display of 
differences, a file-by-file list of differences, an interleaved 
list of differences, a list with change bars, or an input file 
for the batch editor. 

The linker binds programs written in the various lan¬ 
guages into executable and shareable images. Share¬ 
able programs permit the storage of code and data used 
by many executable images as a single disk file and 
permit this code and data to be shared in physical mem¬ 
ory at image run-time. The linker encourages the modu¬ 
lar development of application systems by permitting 
images to be written as small modules and then bound 
into a large image, and by binding programs written in 
different languages. (Programs written in all native-mode 
languages can call one another.) The large per-process 
address space provided by the system removes any 
requirement for program overlays. 

The VAX Common Run-Time Procedure Library provides 
general string manipulation, I/O and I/O conversion, ter¬ 
minal independent screen handling, date/time, mathe¬ 
matics, G_ and H_floating point emulation, resource allo¬ 
cation, signaling and condition handling, syntax analysis 
routines and cross reference procedures that can be 
called from programs written in VAX MACRO or any 
optional, native-mode high-level languages. 

The common run-time procedure library provides 
run-time support for the VAX native-mode, high-level 
languages Ada®, BASIC, C, COBOL, FORTRAN, PAS¬ 
CAL, PM, RPG, and SCAN. All routines in the common 
run-time library follow standard call and condition han¬ 
dling conventions and most are contained within a share¬ 
able image. 
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At a lower level, programs can call the system directly for 
event flag, asynchronous system trap, logical name, re¬ 
cord and file I/O, process control, timer, conversion, 
condition handling, lock management, and memory man¬ 
agement services. Again, the system uses standard call 
and condition handling conventions. 

Programmers using native mode, high-level languages 
need not worry about the mechanics of calling the com¬ 
mon run-time procedures or the base system services. 
The necessary functions are built into the VAX lan¬ 
guages. However, the various levels of detail are avail¬ 
able for those with special requirements, for example, 
programmers constructing real-time applications. In addi¬ 
tion, the user can add procedures to the common 
run-time procedure library and can write new system 
services. 

A system utility, sort/merge, creates sorted files from 
unsorted binary or character input and merges several 
sorted files into one, in ascending or descending se¬ 
quence based on one or more keys. 

The sort/merge routines can be invoked as a utility 
through DCL commands or can be called as subroutines 
by user programs. In addition to the usual record sort, 
the sort/merge routines provide tag, address, and index 
sorts. 

A librarian utility permits the programmer to efficiently 
store object modules, macros, help text, or any general 
record-oriented information in central, easily accessible 
files. Object modules are automatically incorporated in 
images by the linker as they are referenced by calling 
programs. Macros are automatically included in the 
source code of VAX MACRO programs as the programs 
are assembled. Programs can call librarian routines to 
access help text or general information stored in a library 
file. 

A symbolic debugger permits programmers to trace pro¬ 
gram execution and to display and modify program con¬ 
tents using the same symbols that are in the source 
code. Working interactively with DCL-like commands, the 
programmer can: 

• Set breakpoints — Specify locations in the program 
where execution will temporarily halt 

• Set tracepoints — Specify locations or operation 
codes which, if used, will cause a message to be 
displayed during program execution 

• Set watchpoints — Specify locations, that, if modified, 
will cause a message to be displayed during program 
execution 

• Step through the program — Execute the program on 
a line-by-line basis 

• Examine locations — Display the contents of a loca¬ 
tion 

• Modify locations — Change data and instructions at a 
location 

• Call routines — Call routines in the program from the 
interactive command level 


• Log the debugger session — Place a record of the 
debugger session in a log file 

• Run from a command procedure — Invoke a com¬ 
mand procedure that contains debugger commands 
(created from a log file and/or an editing session) to 
rerun a previous session, to continue a previous ses¬ 
sion, or to check a series of items in the program 

Expressions and data formats are generally similar to 
those of the language in which the program being 
debugged is written. 

A patch utility permits the modification of programs with¬ 
out recompilation and linking. Fixes are applied directly to 
the executable image files. Locations in programs, how¬ 
ever, can be addressed using the same symbols that are 
in the source code (i.e., the programmer does not have 
to interpolate from listings and maps). In addition, the 
utility automatically relocates patches that are larger than 
the program content being replaced. 

The definition, creation, loading, and maintenance of 
efficient VAX RMS Indexed Sequential (ISAM) files is 
facilitated by a set of utilities that are integrated by a 
common File Definition Language (FDL). Analysis of the 
current state of any RMS file provides information on the 
file’s internal efficiency and validity. The space efficiency 
of an RMS ISAM file can be improved with a reclamation 
utility. The most appropriate set of RMS file parameters 
can be found with an RMS file tuning tool. The utilities 
that create, efficiently load and reclaim space in RMS 
files can all be called by user programs as well as 
invoked from the DCL command language. They reside 
in shareable images. 

Operations 

The basic unit of execution in VAX/VMS is the process, 
which consists of context and executable images. The 
context identifies the process and describes its current 
state. The executable images consist of system and/or 
user programs that have been compiled and linked. 

Processes receive processor time for the execution of 
their images on an event-driven, pre-emptive priority ba¬ 
sis. Each time an event such as an I/O interrupt occurs, 
the system services the event, then passes control to the 
highest priority process ready to execute (even if the 
process that had control before the event could continue 
to execute). Processes can be assigned base priorities in 
the range of 0 to 31, with 4 (as a typical default) the norm 
for time-sharing users and applications that are not time 
critical. The system automatically adjusts priorities whose 
bases are in the range of 0 to 15 to favor l/O-bound 
processes. Interactive users do not have to wait long 
periods while computation bound processes tie up the 
processor. Real-time processes can be assigned higher 
priorities to ensure that they receive processor time 
whenever they are ready to execute. The system does 
not adjust priorities whose bases are in the range of 16 
to 31, nor does it raise above 15, priorities whose bases 
are in the range of 0 to 15. 
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Processes can be started in the following ways: 

• User log-in — When an interactive user logs in, the 
system creates a process for the user. The process 
provides an environment in which the user can com¬ 
municate with the system to name images to be 
executed and to perform other activities. 

• Explicit creation — A user can specify the creation of 
a new process. In creating a process, the user names 
an image that will be executed when the process 
starts. 

• Batch job — A user can name images to be executed 
and other activities to be performed and can submit 
this information to the system as a batch job either 
from a terminal or a card reader. 

The system queues batch jobs for execution. The user 
can regulate the number of queues and the number of 
streams per queue (that is, the number of batch jobs in 
the queue that can execute concurrently). Time-sharing 
users can enhance performance by restricting interactive 
use of the system to work that requires immediate re¬ 
sponses (such as editing), by submitting as batch jobs, 
work that requires lengthy execution times, and by limit¬ 
ing batch streams to a number that is reasonable for the 
system configuration. 

Different batch job queues may have different attributes 
such as the maximum CPU time permitted, working set 
size, and priority. Facilities are provided for starting and 
stopping queues, as well as the jobs in a queue. Jobs in 
a given queue may be removed or held until a particular 
time. 

Peripheral devices can be controlled by the system or 
allocated by individual processes. At least one disk must 
be a system disk. Users can designate other disks as 
system or group disks for the general use of all users 
logging into the system or for a subset of users known as 
a "group”. Interactive terminals are controlled by the 
system, and the system normally controls one or more 
printers. 

Print queues, both generic and specific (with forms rec¬ 
ognition) together with queue management facilities give 
the user versatile print capabilities. 

The system manager or operator designates 
system-controlled printers as spooled devices associated 
with output queues. Processes submit printed output as 
jobs to these output queues. Within each queue, print 
jobs are processed serially by priority; jobs with the same 
priority are processed serially by priority; print jobs with 
the same priority can be processed either on a 
first-in/first-out basis or by print job size (smallest job 
first). A generic output queue can be associated with one 
or more print queue and, therefore, with one or more 
printers, in this scenario, the next job entered in the 
generic queue is submitted to the first available print 
queue. Special forms and printer characteristics can be 
specified. Print jobs can be stopped, held, requeued, 
positioned (forward or backward), and aborted. 


Processes can allocate devices that are not for general 
use. For example, an interactive user might allocate a 
tape drive on which to back up some disk files. An 
application system might allocate 12 terminals, two disk 
drives, and a printer to be used exclusively for certain 
production work. 

Each process is permitted an address space as large as 
four gigabytes (one of which is reserved) with an upper 
limit of one gigabyte on program size. In practice, pro¬ 
cesses use more modest address spaces; but even so, 
many processes, some requiring extensive space, can 
be running concurrently. VAX/VMS uses the following 
two mechanisms to provide sufficient physical memory 
for the many processes using the system: 

• Paging — The system allots physical memory to a 
process as needed up to a user-specified limit 
(typically in the ranges of 100 to 200 kilobytes for 
interactive users and 200 to 300 kilobytes for batch 
jobs). If memory in excess of the limit is needed, the 
system allows the physical memory requirements to 
expand to a quota and then releases some of the 
process code and data already in memory (taking 
care to preserve modifications) to make room for the 
new code and data. The released code and data are 
initially cached in memory in case they are needed 
again, but later they may be removed from physical 
memory (modifications being written to disk) depend¬ 
ing on process directives and total system operations. 

• Swapping — If too many processes exist to fit in 
physical memory, the system stores some of the pro¬ 
cesses on disk. The system monitors process status 
changes and ensures that the highest priority pro¬ 
cesses ready to execute are in physical memory. In 
addition, the system will attempt not to swap an exe¬ 
cutable process out of memory, until the process has 
accomplished work for a minimum (configuration- 
specified) period of time. 

Paging and swapping should not be high overhead activi¬ 
ties as long as concurrent processes do not exceed a 
reasonable number for physical memory, secondary stor¬ 
age, and the types of processing being performed. The 
in-memory cache for released code and data, the tech¬ 
nique of paging each process against itself, and the 
assurance that ready-to-execute processes are in mem¬ 
ory combine to minimize overhead. 

If desired, processes can exercise control over memory 
management. A real-time process, for example, could 
inhibit the paging and/or swapping of critical code and 
data. 

The system maintains structures in physical memory for 
sharing code and data among processes, for synchroniz¬ 
ing image execution among processes, and for communi¬ 
cating (sending messages) among processes. User 
processes create and control the structures by request¬ 
ing appropriate services of the system. Nonshared struc¬ 
tures and shared structures can be protected against 
access by other processes. 
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The system minimizes operating system overhead by 
taking advantage of the following VAX hardware fea¬ 
tures: 

• Context switching and queue instructions — To 
schedule processes quickly and efficiently 

• Software interrupt delivery mechanism — To minimize 
the processor time required to return from performing 
a service 

• Asynchronous system trap delivery mechanism and 
queue instructions — To minimize the processor time 
required for I/O processing 

• Interrupt priority levels — To improve I/O response 
time 

Reliability 

The system handles errors as transparently as possible 
while maintaining data integrity and providing sufficient 
information to diagnose the errors. The system limits the 
effects of an error by first attempting to recover from the 
error, then if recovery fails, by reporting the error to the 
current process for action, and finally (if the error cannot 
be clearly bounded), by shutting down and restarting the 
system. VAX/VMS will shut itself down rather than con¬ 
tinue operating with a condition that could propagate 
undetected bad data. The types of errors possible are as 
follows: 

• Processor errors (machine checks) — The system 
retries the instruction on which the processor failed, 
as long as no internal state has been modified. If no 
retry is possible or the retry fails, the system reports 
the error to the current process as an exception. 
However, if the executive is currently executing, the 
system shuts down and performs a cold restart by 
bootstrapping a fresh copy of VAX/VMS from the 
system disk. 

• Operating system errors (system errors or undetected 
hardware failures) — The system checks its internal 
data structures for consistency to provide early detec¬ 
tion of a system error. If the error affects only a single 
process, the system reports the error to the process. 
If the error affects more than one process, the system 
shuts down and performs a cold restart by 
bootstrapping a fresh copy of VAX/VMS from the 
system disk. 

• User errors (user bugs) — The system uses hardware 
and software protection mechanisms to prevent pro¬ 
cesses from damaging one another and from damag¬ 
ing the system. As with a system error, the system 
detects a user error through internal consistency 
checks and reports the error to the single affected 
process. 

• Memory errors — The system examines memory at 
start-up time and does not use any pages found to be 
bad. During system operation, the hardware trans¬ 
parently corrects all single-bit memory errors. An 
unrecoverable error causes the memory page on 
which the error occurred to be added to the bad page 
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list: if the page has not been modified, system opera¬ 
tion continues with a new copy of the page. (Unre¬ 
coverable memory errors that occur during a read by 
an I/O device are reported to the device so that the 
I/O operation can be reported as failed.) 

• I/O errors — The system automatically retries failed 
I/O operations to recover from transient errors and 
marginal media conditions. Disk I/O errors are retried 
using the hardware recovery mechanisms. Optionally, 
the system validates disk I/O transfers with read- 
check and write-check functions. If an I/O request 
cannot be completed, all data that was correctly trans¬ 
ferred is returned to the initiator. 

The system logs all processor errors, all operating sys¬ 
tem errors detected through internal consistency checks, 
all double-bit memory errors (and a summary of cor¬ 
rected single-bit errors), and all I/O errors. The log can 
be printed or examined interactively to locate failed and 
troublesome components. 

If the effects of an unrecoverable error cannot be limited 
to a process, the system shuts down and restarts without 
operator intervention by bootstrapping a fresh copy of 
VAX/VMS from the system disk (although the user can 
inhibit the automatic restart feature). Whenever the sys¬ 
tem fails, a dump of physical memory is taken; the dump 
includes the contents of the processor registers. Addi¬ 
tionally, an entry is made in the error log indicating the 
hardware and software states of the machine at failure. 
A utility that can access system data structures symboli¬ 
cally is provided for analyzing dumps. 

On a power failure, the system shuts down automatically. 
On power restoration, the system restarts automatically 
and resumes processing at the point of interruption if the 
system has a time-of-day clock and a memory battery 
back-up unit, and if the contents of memory are still valid. 
The system restarts devices and communications lines. 
All I/O operations in progress, including magnetic tape, 
are restarted. On request, programs can be notified of 
power restoration. An optional battery operated hardware 
clock resets the date and time of day when the system 
restarts. If the system does not have a battery backup 
unit, or if the memory contents are not valid on power 
restoration, the system will perform a cold start (reboot). 

If for any reason the system disk does not come back on 
line after a power failure within a specific time after the 
CPU regains power the system shuts down. 

Diagnostics can be run on individual devices during nor¬ 
mal system operation. 

Certain critical components can operate in degraded 
mode. For example, the memory cache can be disabled. 
The system places a component in degraded mode 
when errors pass a threshold. 

VAX/VMS includes a User Environment Test Package, 
which verifies that the major hardware components of the 
system are complete, properly installed, and ready for 
use. This package can be executed as part of system 
installation, or it can be run in stand-alone mode at any 
time. One binary version of the operating system is 
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created and distributed for each major release of 
VAX/VMS. Patches are applied through an automatic, 
machine-readable, maintenance update procedure. Each 
patch checks for the proper version number and revision 
level, and updates these figures as appropriate. 

Security and Control 

VAX/VMS provides privilege, protection, and quota 
mechanisms to limit user access to system-controlled 
structures in physical memory, system-structured files 
and volumes, and certain devices. Typically, one or a few 
users (system managers and/or operators) who maintain 
the system on a day-to-day basis have unlimited access 
to the system, while the access rights of the remaining 
users are strictly limited. 

User accounts maintained in a user authorization file 
constitute the basis for privilege and quota assignment. 
The system manager can modify this file through ser¬ 
vices provided by the system. Each user account 
identifies a user by name and password. To login and 
gain access to the system, the user must supply this 
name and password, passwords can never be displayed. 
(Even users submitting batch jobs from card readers 
must supply a name and password.) The password is 
encoded and does not appear on displays; once logged 
in, the users can change their passwords. In each user’s 
account, the system manager assigns privileges and 
sets quotas on activities and structures that consume 
system resources, e.g., physical memory, CPU time, disk 
space, etc. 

Login security includes breakin detection which allows 
terminals to be disabled when a breakin attempt is de¬ 
tected. The user is also informed at login as to the last 
time login was done for the account. Secure serving 
provides a means to prevent user programs from initiat¬ 
ing the login process to obtain user-names and pass¬ 
words. 

The System Manager also has the ability to limit each 
user to specific time of day access, such as allowing a 
user to only have access to the system from 9 AM to 5 
PM. 

Access control lists exist and allow more flexible protec¬ 
tion for files, and devices. These lists also allow for the 
logging of successful and unsuccessful attempts to ac¬ 
cess files. 

Each user receives a user identification code (UIC), on 
which the protection mechanism is based. The UIC is 
associated with each structure, file, volume, and device 
that the user owns. For example, when the user creates 
a file, the system associates the user’s UIC with the file. 
The system also attaches a user-specified protection 
mask that permits and/or prohibits categories of access 
to the protected entity. Typically, a protection mask might 
permit all users to read a data file, while permitting only 
the owner to modify or delete it. The protection mecha¬ 
nism also permits users to associate in groups, such that 
access can be permitted to all members of the group and 
denied to all others. 

Scavenge protection is also provided in three forms. File 
high-water marking prevents users from reading beyond 
the end of a file mark. Erase on delete insures that 


information in a file is zeroed before being returned to 
general use. Erase on extend prevents a user from 
reading information that may have been previously allo¬ 
cated to another file. 

Each of these scavenge protection mechanisms may be 
enabled or disabled individually, by a user with appropri¬ 
ate privileges. Security alarms are provided on both a file 
and a system-wide basis. A class of operations may be 
defined to receive security related messages. 

Note, however, that DIGITAL does not warrant that the 
system is secure, although DIGITAL will fix any security 
problem that is brought to our attention in a future re¬ 
lease of VMS. 

Input/Output 

I/O directives can be specified on the following levels: 

• DCL commands — Commands such as EDIT, CRE¬ 
ATE, APPEND, COPY, PRINT, TYPE, SORT, and 
DELETE provide the nonprogramming user with the 
ability to manipulate files. 

• High-level programs — Programs written in COBOL, 
FORTRAN, BASIC, PASCAL, C, PL/I and other 
high-level languages can perform I/O using standard 
language elements. Application programmers will find 
this level the simplest and most efficient in most 
cases. 

• VAX Record Management Services (RMS) — VAX 
RMS consists of a set of routines that MACRO and 
high-level language programs can call for 
device-independent I/O. VAX MACRO and VAX 
BLISS-32 programmers will find VAX RMS the most 
efficient level in most cases. 

• Queue I/O (QIO) system services — The QIO system 
services are direct calls to the operating system. Pro¬ 
grammers can use this level of I/O to perform special 
device dependent functions and to eliminate the sys¬ 
tem overhead involved in RMS; for example, to re¬ 
spond to interrupts from real-time devices as rapidly 
as possible. 

A special program called a device driver executes I/O 
instructions to actually effect the data transfers. Each 
different type of I/O device requires its own driver. 
DIGITAL supplies drivers for all devices supported by 
VAX/VMS, and users with special needs or nonstandard 
devices can write their own drivers. (The VAX/VMS docu¬ 
mentation set includes the "VAX/VMS Guide to Writing a 
Device Driver.”) Additionally, the system provides ser¬ 
vices for programs to bypass the driver mechanism and 
handle device interrupts directly for certain UNIBUS de¬ 
vices. 

DIGITAL supplies a set of programs called ancillary con¬ 
trol processes (ACPs), which maintain standard struc¬ 
tures associated with disk, tape, network, and remote 
terminal I/O. When a new file is created on a structured 
disk volume, for example, the disk ACP will update the 
volume’s directory. 

The I/O routines of the native mode, high-level lan¬ 
guages and native-mode utilities are built on top of VAX 
RMS, which uses the QIO services; thus, all I/O within 
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the system is standard, unless the user elects to bypass 
the DIGITAL-supplied mechanisms. Supported devices 
include disks, tapes, unit record equipment, terminals, 
networks, and mailboxes (virtual devices for interprocess 
communication). VAX RMS provides both record access 
to supported file organizations and an option to bypass 
record processing; thus, a program can address blocks 
within a file directly. 

VAX RMS supports sequential, relative, stream, and 
multiple-key indexed disk files. Sequential, relative, and 
indexed files can be shared for reading, writing, updating, 
and deleting records. The system automatically locks 
and releases records as they are processed. In addition, 
the programmer can lock and release records explicitly. 
For shared files, the user can optionally request that 
RMS allocate I/O buffers in a shared global section. 
Depending on the application, this could reduce the total 
amount of physical memory used for I/O buffers and/or 
reduce the amount of disk I/O necessary for processing 
a file. For other record formats, the user must assume 
responsibility for an interlocking mechanism. (Compatibil¬ 
ity mode programs can also use RMS, but cannot use 
record locking or file sharing.) 

Disk and Tape Volumes 

Disk volumes can be organized into volume sets. Files of 
any organization type can span any number of volumes 
within a volume set. They can be allocated to the set as 
a whole (the default) or to specific volumes within the set. 
Volume sets can contain a mix of disk device types and 
can be extended by adding volumes. Optionally, speci¬ 
fied portions of indexed files can be allocated to specified 
areas of a single disk volume or to specified volumes in a 
volume set. 

Quotas can be placed on the amount of space individual 
users can allocate. Quota assignment is by UIC and may 
be controlled individually for each volume set in the 
system (or volume if the volume is not part of a set). 

Structure information can be cached in memory to re¬ 
duce the I/O overhead required for file management 
services. Although not required to do so, users can 
preallocate space and control automatic allocation. For 
example, when a file is extended, it can be extended by 
a given number of blocks, contiguously or 
noncontiguously for optional file system performance in 
specific cases. 

The system applies software validity checks and 
check-sums to critical disk structure information. The 
critical information is duplicated. If a volume is improperly 
dismounted because of user error or system failure, its 
structure information is automatically rebuilt the next time 
it is mounted. The system detects bad blocks dynami¬ 
cally and prevents their reuse once the files to which the 
blocks were allocated are deleted. 

The system provides eight levels of named directories 
and subdirectories, whose contents are alphabetically 
ordered. Device and file specifications follow standard 
conventions. Logical names can be used to abbreviate 
the specifications and to make application programs de¬ 
vice and file-name independent. A logical name can be 


assigned to an entire specification, to a portion of a 
specification, or to another logical name. 

VAX/VMS supports multi-volume magnetic tape files with 
transparent volume switching. Access positioning is ei¬ 
ther by file-name or by relative file position. 

System utilities that aid in file maintenance include: 

• File transfer — Transfers files from one volume to 
another; files can be in any of several formats. 

• Backup/restore — Provides comprehensive, on-line 
and stand-alone full volume, and incremental file 
backup for file structured mounted volumes and vol¬ 
ume sets. Files can be backed up to magnetic tape or 
another disk. Individual files, selected directory struc¬ 
tures, or all files on a volume set can be backed up 
and restored using standard file naming conventions 
with selection by date. Backup/restore takes place 
onto previously initialized and mounted volumes or on 
uninitialized media. The N + 1 redundant recording 
technique permits recovery of backed up data even if 
one of the N blocks has been corrupted. In the case 
of incremental backups, detection that a file has not 
been modified since the last backup eliminates the 
unnecessary movement of data. It is also possible to 
completely restore a volume or volume set from a 
series of (for example) daily incremental backups. 
Backup and restoration of disk files can be selectively 
performed on-line or on a per-volume basis off line. 
Per-volume operations require exclusive access to the 
volume. 

• Bad block locator — Locates and records bad blocks 
on a disk. 

• Analyze disk structure — Validates structure informa¬ 
tion on a disk volume against the actual contents, 
prints structure information, and permits changes to 
structure information. 

Intersystem Facilities 

DECnet-VAX interfaces and the associated documenta¬ 
tion are integral parts of VAX/VMS. 

The VAX/VMS kit includes that portion of DECnet-VAX 
code for use on a stand-alone local node, not physically 
connected to any other system. This capability allows 
users to design applications using distributed techniques 
with considerations for expansion to a network in the 
future. A DECnet-VAX software license and distribution 
kit are required for each VAX/VMS system physically 
connected to a DECnet network. (For more details on the 
DECnet-VAX product refer to the DECnet-VAX Software 
Product Description, SPD 25.03.xx.) 

Examples of network participation for VAX to VAX com¬ 
munication include: 

• Network Command Terminal Facility (requires optional 
DECnet-VAX on each node) — Allows an authorized 
user to connect and log onto a remote VAX/VMS 
system. Once logged onto the remote system, the 
user can connect and log onto yet another VAX sys¬ 
tem, or proceed to use DCL commands as if on the 
local VAX system. 
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• Mail messages to remote systems (requires optional 
DECnet-VAX on each node) — Can be sent to other 
VAX systems using the personal VAX/VMS MAIL 
utility. 

Local Area Networks 

In addition to the DECnet-VAX ability to use Ethernet for 
communication with other DECnet nodes, VAX/VMS pro¬ 
vides device drivers for all DIGITAL Ethernet adapters. 
Application programmers may use the QIO system ser¬ 
vice to communicate with other systems connected via 
the Ethernet using either Ethernet or IEEE 802.3 packet 
format. Simultaneous use of DEC Ethernet and IEEE 
802.3 protocols are supported on any DIGITAL Ethernet 
adapter. Refer to the DECnet-VAX Software Product 
Description (SPD 25.03.xx) for further information on 
supported communications devices. 

DIGITAL’S terminal server products can be used for ter¬ 
minal access to VMS. An application running under VMS 
can also establish a connection to other devices at¬ 
tached to such terminal servers. 

Shared Memory 

The optional MA780 multi-port memory controller pro¬ 
vides a means for processes on different systems to 
communicate at the speed of accessing memory. Up to 
four VAX-11/780 processors can be physically con¬ 
nected to one multi-port memory controller of 256 to 
2048 kilobytes, and up to two multi-port memory control¬ 
lers can be physically connected to one processor. 
Through a utility, the VAX/VMS user can set up a 
multi-port memory controller to contain the standard 
interprocess structures for sharing code and data, for 
synchronizing image execution, and for sending mes¬ 
sages. In this way, a process on one system can create 
a message in multi-port memory and a process on an¬ 
other system can read that message out of the same 
memory location. Users can also place their own data 
structures in multi-port memory. 

The VAX-11/782 uses MA780 shared multi-port memory 
in a way that is mutually exclusive with that described 
above. 

Attached Processor Support 

VAX/VMS support of the attached processor found on 
the VAX-11/782, VAX 8300, and VAX 8800 is transpar¬ 
ent to the VAX/VMS user. The scheduling of the two 
CPUs, with VAX/VMS running in shared memory, is 
handled deep in the kernel of VAX/VMS and thus is 
hidden from software layers above. The user of 
VAX/VMS in this environment enjoys all the capabilities 
of VAX/VMS while transparently reaping the benefits of 
the power of a multi-processor system. This form of 
multi-processing is most effective with compute intensive 
applications 

VAXcluster Support 

A VAXcluster configuration is a system that combines 
two or more VAX processors, and mass storage servers 
(if desired) in a loosely coupled manner. Clustering via a 
highspeed bus called the Computer Interconnect (Cl) is 
possible with the following processors: 


VAX-11/750 

VAX 

8500 

VAX-11/780 

VAX 

8530 

VAX-11/782 

VAX 

8550 

VAX-11/785 

VAX 

8600 

VAX 8200 

VAX 

8650 

VAX 8250 

VAX 

8700 

VAX 8300 

VAX 

8800 


VAX 8350 

The mass storage server in the Cl environment is a 
free-standing, high-speed, intelligent service designed to 
the specifications of the DIGITAL Storage Architecture 
and known as the Hierarchical Storage Controller, either 
the HSC50 or the HSC70. Each VAX processor or 
HSC-series controller in a Cl-based VAXcluster is called 
a node. Up to 16 nodes may be connected in such a 
Cl-based VAXcluster. 

VAXcluster system disks can be configured in several 
different ways: 

• One common system disk for all nodes in the cluster 

• Individual system disks for each node in the cluster 

• Any combination of common or individual system 
disks 

Note: Each VAX must have only one system disk. 
Common system disks must be served by an 
HSC-series controller. 

Note: All nodes in a VAXcluster must be running the 
same version of VMS. Mixed versions may be 
supported temporarily during a rolling upgrade 
procedure. 

Clustering is also possible over a 10 Megabit/Second 
Ethernet link. Such clusters, known as Local Area 
VAXclusters, are identical in software features to 
Cl-based VAXclusters. For more information on Local 
Area VAXclusters, see the Local Area VAXcluster Soft¬ 
ware Product Description (SPD 27.65.xx). 

VAXcluster software features include the following: 

• System Communications Services — System Com¬ 
munication Services (SCS) is the protocol used over 
the Cl by VMS. This high-performance protocol uti¬ 
lizes the Cl hardware for efficient data transfer be¬ 
tween cluster nodes. 

• Network Interconnect System Communications Ser¬ 
vices — The Local Area VAXcluster Software pro¬ 
vides the Network Interconnect Systems Communica¬ 
tions Services protocol (NISCS) to utilize the Ethernet 
for data transfer between cluster nodes. 

• Connection Manager — The Connection Manager 
uses the System Communication Services to provide 
an acknowledged message delivery service for higher 
VMS software layers. The Connection Manager also 
tracks cluster state changes, i.e., nodes, joining or 
leaving the cluster. 
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• Distributed Lock Manager — The Distributed Lock 
Manager synchronizes access to resources within the 
VAXcluster. The lock database is distributed through¬ 
out the cluster; consequently, access to shared re¬ 
sources from cooperating processes on different VAX 
processor nodes may be synchronized. Deadlock de¬ 
tection has been expanded to be cluster-wide and 
should a VAX processor fail, all locks held by the 
failed VAX processor are released. This allows pro¬ 
cessing to continue on the remaining VAX proces¬ 
sors. 

• Distributed File System — The Distributed File Sys¬ 
tem allows all VAX processors to share disk mass 
storage, whether the disk is connected to an 
HSC-series controller or to a VAX processor. All clus¬ 
ter available disks appear as if they are local to every 
VAX processor. 

• Record Management Services — Record Manage¬ 
ment Services (RMS) has been enhanced to take 
advantage of the Distributed File System and the 
Distributed Lock Manager. RMS files may be shared 
cluster-wide to the record level. 

• Distributed Job Controller — The Distributed Job Con¬ 
troller allows the job controller database to be placed 
on a shared disk, making it available from any VAX 
processor in a VAXcluster. This allows cluster-wide 
batch and print queues to be implemented. 
Cluster-wide batch queues allow batch jobs submitted 
from any VAX processor to be placed on a 
cluster-wide queue. Cluster-wide print queues are 
also a feature of the Distributed Job Controller. 
Printing jobs submitted from any VAX processor may 
be printed on the least loaded printer in the 
VAXcluster. Alternatively, printing may be placed on a 
specific device queue anywhere in the VAXcluster. 
This gives the VAXcluster a basic form of load balanc¬ 
ing capability, since the batch job distribution algo¬ 
rithm numerically balances the batch jobs over the 
VAX processors. 

• The Mass Storage Control Protocol Server — The 
MSCP Server provides a VAX-to-VAX version of the 
MSCP disk I/O services, allowing disks connected to 
other VAX processors, (e.g. MASSBUS disks or DSA 
disks connected to a UDA50) to be shared throughout 
the VAXcluster. 

• Show Cluster Utility — This dynamic display utility 
shows the status of the VAXcluster, giving the status 
of each node, cables, connections, SCS traffic, 
VAXcluster membership and Connection Manager 
traffic. 

• DECnet and the Cluster — All VAX processor nodes 
in a VAXcluster must be licensed for either end-node 
or full-function DECnet-VAX. Some VAXcluster fea¬ 
tures, e.g., cluster node name, require at least one 
node licensed for full-function DECnet-VAX and con¬ 
figured as a routing node. Refer to the DECnet-VAX 
Software Product Description (SPD 25.03.xx) for fur¬ 
ther information about the DECnet-VAX product. 


DECnet-VAX supports the ability to access some or 
all nodes in a VAXcluster using a separate alias node 
address, while retaining the ability to address each 
node in the cluster individually. Not all network objects 
may be accessed using this mechanism. 

Also, DECnet is needed if process-to-process com¬ 
munication is desired between processes on different 
VAXcluster nodes under program control. The MONI¬ 
TOR utility requires multi-node DECnet-VAX for some 
MONITOR activities. 

Installation 

VAX/VMS systems are distributed as binary kits on tape 
or disk. Procedures for setting up the system disk from a 
kit and for readying the system for day-to-day operations 
are simple and straightforward. The binary kit includes 
the following facilities: 

• System installation package 

• System configuration procedures 

• User Environment Test Package 

• Operating system kernel, including virtual memory 
manager, swapper, system services, and drivers for 
VAX/VMS supported I/O devices 

• System generation utility (for tailoring system parame¬ 
ter files) 

• User authorization control program 

• Interactive and batch job controller and symbiont 
manager 

• Card reader input symbiont 

• Line printer output symbiont 

• Bootstrap utility 

• Start-up procedure 

• Shut-down procedure 

• Accounting manager 

• Accounting report utility 

• Operator communication process 

• Message utility 

• MAIL utility (requires optional DECnet-VAX on each 
node for remote mail to another VAX/VMS system) 

• Error logging and print utility 

• Help facility 

• DCL command interpreter 

• DCL command definition utility 

• Monitor utility (for displaying system activity) 

• Various interactive and batch editors 

• Text formatter (DIGITAL Standard Runoff) 

• Log-in facility 
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• Network command terminal facility (allows remote 
log-in to another VAX system if the optional 
DECnet-VAX software license and kit is installed on 
each node) 

• Phone facility — An interactive communications utility 
with networking capability (requires the optional 
DECnet-VAX software license and on each node for 
remote communication) 

• VAX MACRO assembler with cross-reference capabil¬ 
ity 

• Linker with cross-reference capability 

• Install utility 

• Librarian utility with cross-reference capability 

• Common run-time procedure library 

• Symbolic debugger (for MACRO and most optional 
native-mode languages) 

• VAX Record Management Services 

• RMS file analysis and validation utility 

• RMS file conversion and loading utility 

• RMS Indexed Sequential file space reclamation utility 

• RMS file design and tuning utility 

• Files-11 ancillary control process 

• Disk quota utility 

• Back-up and restore facilities 

• Disk structure analysis 

• Magnetic tape ancillary control process 

• Sort/merge utility 

• File management facilities 

• File differences utility 

• File search utility (for searching the content of files) 

• Dump utility 

• Patch utility 

• System dump analyzer 

• Bad block locator utility 

• Software maintenance update procedure 
Tailoring Facility 

Tailoring is supported on processors with small disk 
configuration (RK07, RC25). Tailoring allows users to 
enjoy the full functionality of VAXA/MS, while providing a 
compact version of the operating system tailored to the 
users’ needs on the system disk. VMS upgrade proce¬ 
dures are not supported in tailored environments. 

Due to space constraints, there is no guarantee that 
products can be installed if user code and data reside on 
the system disk. The execution environment supports all 


application programs as long as layered products or 
optional software are NOT DEPENDENT on optional 
software run-time components which are not supported 
in the tailored environment. (Refer to the product’s SPD 
and VAX/VMS System Software Ordering Table (SPD 
28.98.xx)) for the optional products supported in the tai¬ 
lored environment). 

VAX/VMS Distribution 

The software installation guides contain a complete list of 
the modules included in the binary kit, as well as instruc¬ 
tions for their installation. 

A source kit is available for users who wish to retrieve 
and modify selected source modules. (Source modules 
are useful as templates for user-written device drivers.) 
This kit contains most modules in source form, but does 
not contain the sources for all modules which are used to 
create the VMS binary kit. Object files are included for 
those modules which are not on the kit in source code 
form. 

Retrieval of selected source modules can occur once the 
source kit is copied to disk. The source kit can be used 
for a complete rebuilding of the system, except as noted 
below. The kit includes the tools (including source 
patches) that DIGITAL used to build the binary kit; how¬ 
ever, any patches released after building the binary kit 
are not reflected in the source kit. 

Although every attempt is made to include accurate 
source modules, corresponding compiler-version mod¬ 
ules, and supporting command procedures, DIGITAL 
does not warrant the ability to build a complete binary kit 
of the system. DIGITAL will neither warrant nor supply 
updates and support services for the compiler-version 
binary modules. No supporting documentation is provid¬ 
ed, and source modules for intermediate updates of 
VAX/VMS are not available. Source kits are available 
only on major releases, (i.e., Versions 3.0, 4.0, 4.2, 4.4 
etc.) and are not updated with any maintenance updates. 
Depending on how much of the source kit is needed, up 
to three RA60 disk drives or equivalent disk space can 
be required for processing the source modules after 
copying them from tape. 

In addition, DIGITAL does not warrant the results of 
using the source kit to change selected portions of the 
system. 

Sources listings on microfiche for the system software 
components are available on an “AS IS” basis without 
DIGITAL warranty expressed or implied. The microfiche 
listings contain most, although not all, of the modules 
which appear in the VMS binary kit. 

Standards 

VAX/VMS is based on the following American National 
Standards Institute (ANSI), U.S. Federal Information Pro¬ 
cessing (FIPS), and International Standards Organization 
(ISO) standards: 

• X3.4-1977 American Standard Code for Information 
Interchange 
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• X3.6-1973 Perforated Tape Code for Information Ex¬ 
change 

• X3.18-1974 One-inch Perforated Paper Tape for Infor¬ 
mation Exchange 

• X3.41-1974 Code Extension Techniques for Use with 
7-bit ASCII 

• X3.42-1975 Representation of Numeric Values in 
Character Strings 

• X3.27-1978 Magnetic Tape Labels and File Structure, 
Level 1 and Level 2. (Level 3 without user file labels 
and buffer offset) 

• FIPS PUB 79 

• X3.39-1973 Recorded Magnetic Tape (1600 BPI, PE) 

• X3.22-1973 Recorded Magnetic Tape (800 BPI, 
NRZI) 

• X3.54-1976 Recorded Magnetic Tape (6250 BPI, 
GCR) 

• X3.26-1970 Hollerith Punched Card Code 

• FIPS PUB 1, 2, 3-1, 7, 13, 14, 15, 16, 22, 25, 26, 35, 
and 37, but not FIPS PUB 17-1 or 46; other FIPS 
PUBs are not applicable 

• ISO 646-1973 7-bit Coded Character Set for Informa¬ 
tion Exchange 

• ISO 1001-1979 Magtape Labelling and File Structure, 
Level 3 

• ISO 2022-1973 Code Extension Techniques for Use 
with ISO 646 

• ISO 3307-1975 Representations of Time of the Day 

SOURCE CODE INFORMATION 

Machine-readable source code as coding examples is 
provided to allow users to more easily access system 
services. In addition, source listings are provided on 
microfiche to enhance serviceability. 

This source code is provided on an “AS IS” basis 
without any warranty of any kind, either expressed or im¬ 
plied. 

MINIMUM HARDWARE REQUIRED 

The minimum hardware requirements are listed below for 
each VAX CPU. Also see “Minimum Cluster” for addi¬ 
tional requirements for those VAX systems which partici¬ 
pate in VAXclusters. 

For VAX-11/725 and VAX-11/730 Systems 

• Two megabytes of memory 

• At least one of the following: 

— One RC25 drive (VAX-11/725 only) 

— One RL02 disk drive and one R80 disk drive 

— One UDA (at least at microcode level Rev. 3) with 
an RA60/80/81/82 disk drive and either an RA60 
disk drive or a TU80/TU81/TU81-PLUS tape drive 


SPD 25.01.28 

For VAX-11/750 Systems 

• Two megabytes of memory 

• Any VAX-11/750 system at ECO Rev. 4 with at least 

one of the following: 

— Two RK07 disk drives 

— One RM03/RM05/RM80 disk drive and one 
TE16/TS11/TU77/TU80/TU81/ TU81 -PLUS mag¬ 
netic tape 

— One CI750, one HSC-series controller (see “Op¬ 
tional VAXcluster Hardware” for correct HSC Soft¬ 
ware version), with an RA60/80/81/82, and 
an RA60 or RK07 or a TA78/TA81/TE16/TU45/ 
TU77/TU78/TU80/TU81 / TU81 -PLUS magtape. 

The CI750 requires the VAX-11/750 system to be 
at least ECO Rev. 5. 

— One UDA (at least at microcode level Rev. 3) with 
an RA60/80/81/82 disk drive and either an RL02 or 
RA60 disk drive, or a TU77/78/80/81 tape drive 

Note: Combinations of UDA50s and CI750s on the 
same VAX-11/750 are supported if the 
VAX-11/750 is at ECO Rev. 7 or later. 

Note: The console TU58 is not available as a user 
storage device. 

For VAX-11/780 and VAX-11/785 Systems 

• Two megabytes of memory 

• Any VAX-11/780 system at ECO Rev. 4 and WCS123 

with at least one of the following: 

— Two RK07 disk drives 

— One RM03/RM05/RM80/RP05/RP06/RP07 disk 
drive and one TE16/TU45/TU77/TU78/TU80/ 
TU81/TU81-PLUS magnetic tape 

— One UDA (at least at microcode level Rev. 3) with 
an RA60/80/81/82 disk drive and an RA60 or a 
TU78/80/81/81 -PLUS tape drive 

— One CI780, one HSC-series controller (see “Op¬ 
tional VAXcluster Hardware” for correct HSC Soft¬ 
ware version), with an RA60/80/81/82, and 
an RA60 or an RK07 or a TA78/TA81/TE16/TU45/ 
TU77/TU78/TU80/TU81 /TU81 -PLUS 

Note: Combinations of CI780s and VAX-11/780s are 
supported if the VAX-11/780 is at ECO Rev. 7 or 
later. 

For VAX-11/782 Systems 

The same requirements as for the VAX-11/780 apply 
except that the minimum amount of shared memory 
(MA780) in this environment is one and one half 
megabytes, and the minimum local memory required for 
diagnostic purposes is one megabyte. 

The two CPUs of the VAX-11/782 system must be at the 
same ECO level Rev. 7 minimum. Both CPUs must have 
the same CPU options, (i.e., if one CPU has an FP780, 
both must have an FP780). 
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The primary CPU has all the input and output adapters 
and interfaces connected to it. The SECONDARY (or the 
ATTACHED) is a bare CPU with 256 kilobytes of local 
memory for diagnostic purposes. Any input and output 
devices on the SECONDARY are ignored. 

For VAX 8200/8250 and VAX 8300/8350 Systems 

• Two megabytes of memory 

• At least one of the following: 

— One KDB50 with an RA60/80/81/82 disk drive and, 
in addition, either an RA60 disk drive or a 
TU80/81/81-PLUS Tape Drive 

— One CIBCI or one CIBCA (VAXcluster Port), one 
HSC-series controller (see "Optional VAXcluster 
Hardware” for correct HSC Software version), with 
an RA60/80/81/82, and an RA60 or a TA78/TA81/ 
TU80/TU81/ TU81-PLUS magtape 

For VAX 8600 and VAX 8650 Systems 

• Four megabytes of memory 

• At least one of the following: 

— One CI780, one HSC-series controller (see “Op¬ 
tional VAXcluster Hardware ” for correct HSC Soft¬ 
ware version), with an RA60/80/81/82 and a 
TA78/81 

— One Integrated Disk and Tape Controller (IDTC) 
with an RA60/80/81/82 and a TU81/TU81-PLUS 


For VAX 8500, VAX 8530, VAX 8550, VAX 8700 and 

VAX 8800 Systems 

• Four megabytes of memory 

• At least one of the following: 

— One KDB50 with an RA60/80/81/82 disk drive and 
a TU80/TU81/TU81-PLUS tape drive 

— One CIBCI or one CIBCA (VAXcluster Port), one 
HSC-series controller (see "Optional VAXcluster 
Hardware” for correct HSC Software version), with 
an RA60/80/81/82, and a TA78 

MINIMUM CLUSTER 


For Cl-based VAXcluster Systems 


Each VAX processor or HSC-series controller in a 
VAXcluster is called a node. Up to 16 nodes may be 
connected in a VAXcluster via a high-speed bus known 
as the Computer Interconnect, or Cl. No other device is 
supported on the Cl. The VAX processors which are 
supported in a Cl-based VAXcluster are: 


VAX-11/750 
VAX-11/780 
VAX-11/782 
VAX-11/785 
VAX 8200 
VAX 8250 
VAX 8300 


VAX 8500 
VAX 8530 
VAX 8550 
VAX 8600 
VAX 8650 
VAX 8700 
VAX 8800 


VAX 8350 


A VAXcluster may consist of any combination of two or 
more supported VAX processors, up to a total of 16 VAX 
Processors. 

A VAXcluster may also consist of any combination of two 
or more supported VAX processors and at least one 
HSC-series controller with at least one RA-series disk, 
and a minimum of either one local tape drive or a 
TA-series tape drive connected to an HSC-series control¬ 
ler. The maximum number of nodes is 16. 

The Cl interface in any VAX/VMS system which partici¬ 
pates in a VAXcluster must be at Microcode Level 7 or 
later. The supported Cl interfaces are the CIBCI, the 
CIBCA, the CI780, and the CI750. 

Each VAX/VMS system in a Cl-based VAXcluster must 
have at least four megabytes of memory. The minimum 
memory requirement for a particular VAX CPU may be 
higher than four megabytes. See individual CPU require¬ 
ments above. 

For Local Area VAXcluster Systems: 

Refer to the Local Area VAXcluster Software Product 
Description (SPD 27.65.xx) for information on minimum 
Local Area VAXcluster Systems. 

VAX/VMS Disk Block Requirements 

Block Space Requirements (Block Cluster Size = 2): 

Disk block size for VAX/VMS, Version 4.6 after installa¬ 
tion is approximately 42,000 blocks. This figure includes 
a 4,600 block page-file. Most systems will require a 
larger page-file, and a swap-file. This figure also includes 
library files which were in data-reduced format. Most 
installations will choose to data-expand these files. This 
would require approximately 3,000 additional blocks. 

This block size will be approximately the same for tai¬ 
lored, normal, and syscommon configurations. For tai¬ 
lored systems, the blocks are distributed on two disks. 
Approximately 6,525 blocks will be placed on the system 
disk, while the remaining blocks will be placed on the 
library disk. 

These sizes are approximations; actual sizes may vary 
depending on the user’s system environment, configura¬ 
tion and options selected. 

GROWTH CONSIDERATIONS 

The minimum hardware requirements for any future ver¬ 
sion or update of VAX/VMS may be different from the 
minimum hardware requirements for the current version. 

OPTIONAL HARDWARE 

Additional memory may be required if additional devices 
are included in the configuration. Additional memory 
and/or secondary storage may be required if multiple 
optional software products are being used concurrently. 

NOTE(1): Combinations of hardware options are subject 
to limitations such as bandwidth, physical con¬ 
figuration restraints and electrical loads/power. 

NOTE(2): Combinations of UDA50s and CI750s on the 
same VAX-11/750 processor are supported if 
the VAX-11/750 is at ECO Rev. 7 or later. 
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VAX configuration details are described in the VAX Sys¬ 
tems and Options Summary. 

For VAX 8800 Systems 

• CPU Options 

— Additional memory up to 128 mb 

— Additional VAXBI channels up to a maximum of 
four 

— One DWBUA UNIBUS adaptor per VAXBI channel 
up to two per system 

— Up to two KDB50 disk controllers per VAXBI chan¬ 
nel and up to eight KDB50s per system. Each 
KDB50 allows any combination of RA60/80/81/82 
disk drives up to a total of four per KDB50 

— Up to two TU81-Plus tape drives per VAXBI, up to 
a maximum of four TU81-PLUS tape drives per 
system 

— One CIBCI or CIBCA, VAXcluster Port 

— Two DMB32 per VAXBI or four per system, eight 
asynchronous, one synchronous and one line- 
printer interface) 

Note: The synchronous port is NOT supported by 
VMS. Support is provided by a layered product 
(DMB32 Synchronous Device Driver. Refer to 
SPD 27.35.xx for details). 

• Communications Devices 

Refer to the DECnet-VAX SPD (25.03.xx) for the 

supported configurations. 

• Real-Time Devices 

— One DR11-W General Purpose High Speed DMA 
interface 

For VAX 8700 Systems 

• CPU Options 

— Additional memory up to 128 mb 

— One additional processor 

— Additional VAXBI channels up to a maximum of 
four 

— One DWBUA UNIBUS adaptor per VAXBI channel 
up to two per system 

— Up to two KDB50 disk controllers per VAXBI chan¬ 
nel and up to eight KDB50s per system. Each 
KDB50 allows any combination of RA60/80/81/82 
disk drives up to a total of four per KDB50 

— Up to two TU81-Plus tape drives per VAXBI for a 
maximum of four TU81-PLUS tape drives per sys¬ 
tem 

— One CIBCI or one CIBCA, VAXcluster Port 

— Two DMB32 per VAXBI or eight per system, (8 line 
asynchronous, one synchronous and one line- 
printer interface) 


Note: The synchronous port is NOT supported by 
VMS. Support is provided by a layered product 
(DMB32 Synchronous Device Driver. Refer to 
SPD 27.35.xx for details). 

• Communications Devices 

Refer to the DECnet-VAX SPD (25.03.xx) for the 
supported configurations. 

• Real-Time Devices 

— One DR11-W General Purpose High Speed DMA 
interface 

For VAX 8600 and VAX 8650 Systems 

• CPU Options 

— Additional memory up to a system total of 260 
megabytes 

— Up to two SBIs 

— Up to four UNIBUS adaptors per SBI (to a system 
maximum of seven) 

— Up to four MASSBUS adaptors per SBI (to a sys¬ 
tem maximum of six) 

— One IDTC (Integrated Disk and Tape Controller) 
— FP86-AA Floating Point Accelerator 
— Up to four DR780s (on the second SBI only) 

— One CI780 

• UNIBUS Disk Systems 

— Up to two UDAs per UNIBUS (at least at microcode 
level Rev. 3) and any combination of 
RA60/80/81/82 disk drives, up to four drives per 
UDA 

— Up to four RL02 disk drives per system (not sup¬ 
ported as a system disk) 

— Up to two RX02 disk drives per system (not sup¬ 
ported as a system disk) 

— One RC25 

— One RUX50 

— One TUK50 

• MASSBUS Disk Systems 

— Up to four MASSBUS adapters can be connected 
to a VAX-11/780. 

MASSBUS adapters are available in MASSBUS 
ADAPTER/DISK SUBSYSTEM combinations, 
(REM03, REM05, REM80, REP05, REP06, 
REP07) that include a MASSBUS adapter and disk 
drive, (RM05, RP07) respectively. Up to seven 
additional disk drives can be added to a subsys¬ 
tem. Different disk drive types can be attached to 
the same disk subsystem; this gives a total of 32 
disk drives per VAX-11/780 system. 

— RP07s are supported at 2.2 MB/sec if the RH780 is 
at Rev. B1 or greater. 
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— Refer to MASSBUS Magnetic Tape Systems for 
information on disks and tapes configured on the 
same MASSBUS. 

• MASSBUS Magnetic Tape Systems 

— MASSBUS adapters are also available in 
MASSBUS ADAPTER/TAPE SUBSYSTEM combi¬ 
nations, (TEU77, TEE16, TEU45, TEU78) that in¬ 
clude a MASSBUS adapter and a specific tape 
formatter and transport (TU77, TE16, TU45, 
TU78), respectively. Up to three additional TU77 or 
TU78 magnetic tape transports can be added to 
each TEU77 or TEU78 subsystem respectively. Up 
to seven additional TE16 or TU45 magnetic tape 
transports can be added to each TEE16 or TEU45 
subsystem, respectively. Different magnetic tape 
transports can not be mixed on the same TExxx 
subsystem. A TU78 Master (which includes TM78 
formatter and a TU78 transport) can be attached to 
any MASSBUS tape subsystem. 

— With disks and magnetic tape transports mixed on 
the same MASSBUS, the following rules apply: 

Disks can be added to a magnetic tape subsystem, 
with up to seven add-on disks per TExxx subsys¬ 
tem. 

Tape transports cannot be added to a disk subsys¬ 
tem. 

— A TU78 Master (which includes a TM78 formatter 
and a TU78 transport) can be attached to a disk 
subsystem. 

The combination of disks and tape formatters must 
not exceed eight on a single MASSBUS. 

• UNIBUS Magnetic Tape Systems 

— TU80 or TU81/TU81-PLUS magnetic tape subsys¬ 
tems, up to a total of four per UNIBUS 

• Card Readers 

— Up to a system total of two CR11 card readers 

• Line Printers 

— Up to system total of 16 LA11, LP11, LP11-A, 
LP11-B, LP11-C, LP11-D, LP11-E, LP11-G, 
LP11-R, LP11-S, LP11-V, LP11-W, LP11-Y, 
LP11-Z, LP27 line printers, the LN03 Laser Printer, 
and the LN01 Laser Printer (at ECO DEC007) 

• Communications Devices 

Refer to the DECnet-VAX SPD (25.03.xx) for the 

supported configurations. 

• Real-Time Devices 

— One DR11-W General Purpose High Speed DMA 
interface 

For VAX 8550, VAX 8530 and VAX 8500 Systems 

— Additional memory up to 80 mb 

— Additional VAXBI channels up to a maximum of 
two 


— One DWBUA UNIBUS adaptor per system 

— Up to two KDB50 disk controllers per VAXBI chan¬ 
nel and up to four KDB50s per system. Each 
KDB50 allows any combination of RA60/80/81/82 
disk drives up to a total of four per KDB50 

— Up to two TU81-Plus tape drives per VAXBI, up to 
a maximum of four TU81-PLUS tape drives per 
system 

— Ore CIBCI or CIBCA VAXcluster Port 

— Two DMB32 per VAXBI up to a total of four per 
system, (eight line asynchronous, one synchro¬ 
nous and one lineprinter interface) 

Note: The synchronous port is NOT supported by 
VMS. Support is provided by a layered product 
(DMB32 Synchronous Device Driver. Refer to 
SPD 27.35.xx for details). 

• Communications Devices 

Refer to the DECnet-VAX SPD (25.03.xx) for the 

supported configurations. 

• Real-Time Devices 

— One DR11-W General Purpose High Speed DMA 
interface 

For VAX 8350, VAX 8300, VAX 8250, VAX 8200 

Configuration 2 Systems 

• CPU Options 

— One addition processor for the VAX 8200 and the 
VAX 8250 

— Additional memory up to a system total of 32 
megabytes 

— One DWBUA UNIBUS adaptor per system 

— Up to four KDB50 disk controller and any combina¬ 
tion of RA60/80/81/82 disk drives up to a total of 
four disk drives per KDB50 

— Up to three TU80/TU81-PLUS tape drives per sys¬ 
tem 

— One CIBCI or one CIBCA, VAXcluster Port 

— One TUK50 tape controller for one TK50 Tape 
Cartridge Drive 

— Up to six DMB32 (eight line asynchronous, one 
synchronous and one lineprinter interface) 

Note: The synchronous port is NOT supported by 
VMS. Support is provided by a layered product 
(DMB32 Synchronous Device Driver. Refer to 
SPD 27.35.xx for details). 

• Communications Devices 

Refer to the DECnet-VAX SPD (25.03.xx) for the 

supported configurations. 

• Real-Time Devices 

— One DR11-W General Purpose High Speed DMA 
interface 
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For VAX 8350, VAX 8300, VAX 8250, VAX 8200 Con¬ 
figuration 1 Systems 

• CPU Options 

— One additional processor for the VAX 8200 and 
VAX 8250 

— Additional memory up to a system total of 24 
megabytes 

— Up to four KDB50 disk controller and any combina¬ 
tion of RA60/80/81/82 disk drives up to a total of 
four disk drives per KDB50 

— One DWBUA UNIBUS adaptor per system 

— Up to two KDB50 disk controller and any combina¬ 
tion of RA60/80/81/82 disk drives up to a total of 
four disks drives per KDB50 

— One TU81-PLUS tape drive per system 
— One CIBCI or CIBCA VAXcluster Port 

— One TUK50 tape controller for one TK50 Tape 
Cartridge Drive 

— Two DMB32 (eight line asynchronous, one syn¬ 
chronous and one lineprinter interface) 

Note: The synchronous port is NOT supported by 
VMS. Support is provided by a layered product 
(DMB32 Synchronous Device Driver. Refer to 
SPD 27.35.xx for details). 

• Communications Devices 

Refer to the DECnet-VAX SPD (25.03.xx) for the 
supported configurations. 

• Real-Time Devices 

— One DR11-W General Purpose High Speed DMA 
interface 

For VAX-11/782 Systems 

All of the VAX-11/780 optional hardware applies to the 

VAX-11/782 except for the following CPU options: 

• KU780 (User Writable Control Store) 

• VAX/VMS runs (or resides) in the MA780 shared 
memory on a VAX-11/782 attached processor config¬ 
uration. The maximum amount of shared memory 
(MA780 memory) that can be on the system is eight 
megabytes (four MA780s with two megabytes on 
each). 

For VAX-11/780 and VAX-11/785 Systems 

• CPU Options 

— Additional memory up to a system total of 64 
megabytes 

— DR780 high-performance, general purpose inter¬ 
face 

— Up to two MA780 multi-port memory controllers per 
system with up to 2048 kilobytes per MA780 con¬ 
troller 


— H7112 memory battery back-up (required for 
power-fail/recovery) 

— FP780 floating-point accelerator 

— DW780 UNIBUS adapter, up to a system total of 
four 

— KE780 G and H floating point microcode 

— KU780 User Writable Control Store 

— One CI780 

• UNIBUS Disk Systems 

— Up to four UNIBUS adaptors 

— Up to eight disk drives per UNIBUS (RK06 and/or 
RK07) 

Note: RK06 is not supported as a system device. 

— Up to two UDAs per UNIBUS (at least at microcode 
level Rev. 3) and any combination of 
RA60/80/81/82 disk drives, up to four drives per 
UDA 

— Up to four RL02 disk drives per system (not sup¬ 
ported as a system disk) 

— Up to two RX02 disk drives per system (not sup¬ 
ported as a system disk) 

— One RC25 

— One RUX50 

— One TUK50 

• MASSBUS Disk Systems 

— Up to four MASSBUS adapters can be connected 
to a VAX-11/780. MASSBUS adapters are avail¬ 
able in MASSBUS ADAPTER/DISK SUBSYSTEM 
combinations, (REM03, REM05, REM80, REP05, 
REP06, REP07) that include a MASSBUS adapter 
and disk drive, (RM03, RM05, RM80, RP05, RP06, 
RP07) respectively. Up to seven additional disk 
drives can be added to a subsystem. Different disk 
drive types can be attached to the same disk 
subsystem; this gives a total of 32 disk drives per 
VAX-11/780 system. 

— RP07 is supported at 2.2 MB/sec if the RH780 is at 
Rev. B1 or greater. 

— Refer to MASSBUS Magnetic Tape Systems for 
information on disks and tapes configured on the 
same MASSBUS 

• MASSBUS Magnetic Tape Systems 

— MASSBUS adapters are also available in 
MASSBUS ADAPTER/TAPE SUBSYSTEM combi¬ 
nations, (TEU77, TEE16, TEU45, TEU78) that in¬ 
clude a MASSBUS adapter and a specific tape 
formatter and transport (TU77, TE16, TU45, 
TU78), respectively. Up to three additional TU77 or 
TU78 magnetic tape transports can be added to 
each TEU77 or TEU78 subsystem respectively. Up 
to seven additional TE16 or TU45 magnetic tape 
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transports can be added to each TEE16 or TEU45 
subsystem, respectively. Different magnetic tape 
transports can not be mixed on the same TExxx 
subsystem. A TU78 Master (which includes TM78 
formatter and a TU78 transport) can be attached to 
any MASSBUS tape subsystem. 

With disks and magnetic tape transports mixed on 
the same MASSBUS, the following rules apply: 

Disks can be added to a magnetic tape subsystem, 
with up to seven add-on disks per TExxx subsys¬ 
tem 

Tape transports cannot be added to a disk subsys¬ 
tem 

— A TU78 Master (which includes a TM78 formatter 
and a TU78 transport) can be attached to a disk 
subsystem. 

The combination of disks and tape formatters must 
not exceed eight on a single MASSBUS. 

• UNIBUS Magnetic Tape Systems 

— TS11, TU80 or TU81/TU81-PLUS magnetic tape 
subsystems, up to a total of four per UNIBUS 

• Card Readers 

— Up to a system total of two CR11 card readers 

• Line Printers 

Up to system total of 16 LA11, LP11, LP11-A, 
LP11-B, LP11-C, LP11-D, LP11-E, LP11-G, LP11-R, 
LP11 -S, LP11 -V, LP11 -W, LP11 -Y, LP11 -Z, LP27 line 
printers, the LN03 Laser Printer, and the LN01 Laser 
Printer (at ECO DEC007) 

• Communications Devices 

Refer to the DECnet-VAX SPD (25.03.xx) for the 
supported configurations. 

• Real-Time Devices 

— Up to a total of two LPA11-K microprocessor con¬ 
trollers per UNIBUS for laboratory data acquisition 
I/O devices, with each LPA11-K able to accom¬ 
modate up to two ADII-Ks, one AA11-K, one 
KW11-K, five DRII-Ks, and two AMII-Ks 

— One DR11-W General Purpose High Speed DMA 
interface 

For VAX-11/750 Systems 

• CPU Options 

— Additional memory up to a system total of fourteen 
megabytes 

— H7112 memory battery back-up (required for 
power-fail/recovery) 

— DW750 second UNIBUS adapter 


— One DR750 high-performance, general purpose in¬ 
terface. The DR750 and the CI750 are not sup¬ 
ported on the same system. 

— KU750 User Writable Control Store 

— FP750 floating point accelerator 

— One CI750 (with 750 at REV 5, if no UDA50 
present or with 750 at REV 7 if UDA50 present) 

• UNIBUS Disk Systems (11/750 may have up to two 

UNIBUS adapters) 

— Up to eight RK07 disk drives per system 

— Up to four RL02 disk drives per system (not sup¬ 
ported as a system device) 

— Up to two RX02 dual-drive subsystems per system 
(not supported as a system device) 

— One RC25 

— One RUX50 

— One TUK50 

— Up to two UDAs (at least at microcode level Rev. 3 
if no CI750 present, or at microcode level Rev. 5, if 
CI750 present) per UNIBUS and any combination 
of RA60/80/81/82 disk drives, up to four drives per 
UDA 

• MASSBUS Disk Systems 

— Up to three MASSBUS adapters can be connected 
to a VAX-11/750. MASSBUS adapters are avail¬ 
able in MASSBUS ADAPTER/DISK SUBSYSTEM 
combinations (RGM03, RGM05, RGM80, RGP06, 
RGP07) that include a MASSBUS adapter and disk 
drive, (RM03, RM05, RM80, RP06, RP07) respec¬ 
tively. Up to seven additional disk drives can be 
added to a subsystem. Different disk drive types 
can be attached to the same disk subsystem; this 
gives a total of 24 disk drives per VAX-11/750 
system. 

— Refer to MASSBUS Magnetic Tape Systems for 
information on disks and tapes configured on the 
same MASSBUS. 

• MASSBUS Magnetic Tape Systems 

— MASSBUS adapters are also available in 
MASSBUS ADAPTER/TAPE SUBSYSTEM combi¬ 
nations. (TGU77, TGE16) that include a 
MASSBUS adapter, a tape formatter and a trans¬ 
port (TU77, TE16 respectively). Up to three addi¬ 
tional TU77 magnetic tape transports can be 
added to a TGU77 subsystem. Up to seven TE16 
magnetic tape transports can be added to each 
TGE16 subsystem. Different magnetic tape trans¬ 
ports cannot be mixed on the same TGxxx subsys¬ 
tem. 


— With disks and magnetic tape transports mixed on 
the same MASSBUS, the following rules apply: 
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Disks can be added to a magnetic tape subsystem, 
with up to seven add-on disks per TGU77 subsys¬ 
tem 

Tapes cannot be added to a disk subsystem. 

• UNIBUS Magnetic Tape Systems (VAX-11/750) may 

have up to two UNIBUSs) 

— TS11, TU80 or TU81/TU81-PLUS magnetic tape 
subsystems, up to a system total of two 

• Card Readers 

— One CR11 card reader 

• Line Printers 

— Up to a system total of four LA11, LP11 -A, LP11 -B, 
LP11-C, LP11-D, LP11-E, LP11-G, LP11-R, 

LP11-S, LP11-V, LP11-W, LP11-Y, LP11-Z, LP27 
line printers, the LN03 Laser Printer, and the LN01 
Laser Printer (at ECO DEC007) 

• Communications Devices 

Refer to the DECnet-VAX SPD (25.03.xx) for the 

supported configurations. 

• Real-Time Devices 

— Up to a system total of two (one per UNIBUS) 
LPA11-K microprocessor controllers for laboratory 
data acquisition I/O devices, each accommodating 
up to two AD11 -Ks, one AA11 -K, one KW11 -K, five 
DRII-Ks, and two AMII-Ks 

— One DR11-W General Purpose High Speed DMA 
interface 

For VAX-11/725 and VAX-11/730 

Note: Combinations of hardware options are subject to 
limitations such as bandwidth, physical configu¬ 
ration restraints and electrical loads/power. 

(VAX configuration details are described in the 
VAX Systems and Options Summary.) 

• CPU Options 

— Additional memory up to a system total of five 
megabytes for VAX-11/730, R80/RL02 and 

RL02/RL02 systems. Up to 3 megabytes for 
VAX-11/725 and other VAX-11/730 systems. 

— FP730 floating point accelerator 

— Up to two RL02 disk drives can be added to the 
dual RL02 and the R80/RL02 Package Systems 

• UNIBUS Disk Systems (11/730 has one UNIBUS) 

— Up to eight RK07 disk drives on one RK711 con¬ 
troller 

— Up to four RL02 disk drives on one RL211 control¬ 
ler* 

— One RX211 floppy disk subsystem (two RX02 
drives) not supported as a system device* 

— One RC25 


— One RUX50 

— One TUK50 

— One UDA per UNIBUS (at least at microcode level 
Rev. 3) and any combination of RA60/80/81/82 
disk drives, up to four drives per UDA 

• Not available on VAX-11/725 

• UNIBUS Magnetic Tape Systems 

— One TS11, TU80 or TU81/TU81-PLUS magnetic 
tape subsystem 

• Card Reader 

— One CR11 card reader 

• Line Printers 

— One LP32 line printer per system, connected to a 
DMF32 

— One LP11 line printer per system with built-in con¬ 
troller 

• Communications Devices 

Refer to the DECnet-VAX SPD (25.03.xx) for the 
supported configurations. 

• Real-Time Devices 

— One DR11-W General Purpose High Speed DMA 
interface 

— Up to a system total of two (one per UNIBUS) 
LPA11-K microprocessor controllers for laboratory 
data acquisition I/O devices, each accommodating 
up to two AD11 -Ks, one AA11 -K, one KW11 -K, five 
DRII-Ks, and two AMII-Ks. 

Optional VAXcluster Hardware for Cl-based VAXclusters 

• The HSC-series Controller 

Each HSC50 supports a maximum of six disk chan¬ 
nels or six tape channels or any combination of up to 
six disk and tape channels. Each HSC70 supports a 
maximum of eight disk channels or eight tape chan¬ 
nels or any combination of up to eight disk and tape 
channels. Each disk channel supports a maximum of 
four disk drives and each tape channel supports a 
maximum of four tape subsystems (with four tape 
drives each). VMS supports a maximum of eight tape 
drives per HSC-series controller. 

Static dual porting of TA-series tapes is supported. A 
dual-path HSC tape drive is a drive that connects to 
two HSCs, both of which have the same non-zero 
tape allocation class. For dual-pathed tape drives, 
VMS automatically selects a functional HSC when 
processing a MOUNT or initialize command. If the 
selected HSC becomes inoperative while a tape is 
mounted, the tape must be dismounted and re-moun¬ 
ted by the operator in order to cause the alternate 
HSC to be used. Note that this is not automatic 
failover, since operator intervention is required. 

The HSC50 and the HSC70 must be running either 
HSC Software, Version 3.5. Static dual porting of 
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TA-series tape drives is supported only if the HSC 
series controller is running HSC Software, Version 
3.5. 

Optional VAXcluster Hardware for Local Area 
VAXcluster Systems 

Refer to the Local Area VAXcluster Software Product 
Description (SPD 27.65.xx) for information on optional 
Local Area VAXcluster Systems. 

Terminals and Terminal Line Interfaces 

To prevent buffer overruns on input the terminals use the 
ASCII control characters DC1 and DC3 for synchroniza¬ 
tion, as defined by DIGITAL’S DEC STD 111, Revision A. 

The list of terminals that are supported and can interact 
with VAX/VMS and its associated utilities are: VT52, 
VT100, VT101, VT102, VT105, VT125, VT131, VT132, 
VT180, VT200 series (VT220, VT240 and VT241), 
VT300 series (VT330 and VT340) and the Professional 
300 series (Professional 325, 350, and 380), the Rain¬ 


bow 100 and DECmate II are supported in VT100 mode. 
In addition, the LAI2, LA34, LA50, LA36, LA38, LAI00, 
LAI 20, LA210, and LQP02 are supported in hardcopy 
mode. There is only limited support for the VT52. 

The VT131 and VT132, when operating in an applica¬ 
tions environment, are supported in block mode. When 
interacting with VAX/VMS and its associated utilities, 
they are only supported in VT100 (or interactive) mode, 
and not in block mode. 

Per UNIBUS, VMS will recognize any mix of controllers 
such that the vector requirements are less than or equal 
to 80. The tables below list the vector requirements for 
each multiplexer. The maximum number of controllers 
recommended is a number which may be less than 
physically connectable, but which makes sense for this 
system in normal configuration. All limits are also subject 
to UNIBUS requirements (slots, power, UNIBUS loads, 
etc.) which may not be included here. 


Table 1 

VAX-11/780, VAX-11/782, VAX-11/785, VAX 8600, VAX 8650 Systems 


Multiplexer 

Lines 

Vector 

Requirement 

Maximum 

Per UNIBUS 

Recommended 

DZ1 1 , DZ32 

8 

2 

12 *r 

12 

DZ11 

16 

4 

6 *r 

6 

DHU11 

16 

2 

12 *r 

10 

DMF32 

8 

8 

12 *2* 

10 

DMZ32 

24 

7 

12 *1* 

8 

Table 2 

VAX-11/750 Systems 

Multiplexer 

Lines 

Vector 

Requirement 

Maximum 

Per UNIBUS 

Maximum 

Recommended 

DZ11, DZ32 

8 

2 

12 *r 

8 

DZ11 

16 

4 

6 *1* 

4 

DHU11 

16 

2 

12 *r 

8 

DMF32 

8 

8 

10 *2* 

8 

DMZ32 

24 

7 

12 *1* 

6 


Table 3 

VAX-11/730 Systems 


Multiplexer 

Lines 

Vector 

Requirement 

Maximum 

Per UNIBUS 

Maximum 

Recommended 

DZ11, DZ32 

8 

2 

12 *1* 

4 

DZ11 

16 

4 

6 *1* 

2 

DHU11 

16 

2 

12 *r 

2 

DMF32 

8 

8 

12 *2* 

3 

DMZ32 

24 

7 

12 *1* 

2 
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Table 4 


VAX 8200, VAX 8250 ,VAX 8300, VAX 8350, VAX 8500, 

VAX 8530, VAX 8550, VAX 8700, VAX 8800 Systems 

Multiplexer 

Lines Vector 

Requirement 

Maximum 

Per UNIBUS 

Maximum 

Recommended 

DHU11 

16 2 

12 *r 

4 

DMF32 

8 8 

12 *2* 

2 

DMZ32* 

24 9 

12 *r 

2 

* Remote device only 





Table 5 

VAX 8200, VAX 8250, VAX 8300, VAX 8350 Configuration 1 


Multiplexer 

Lines Vector 

Requirement 

Maximum 

Per Bl 

Maximum 

Recommended 

DMB32 

8 4 

2 

2 ** 

* up to 6 DMB32 for Configuration 2 




Table 6 

VAX 8500, VAX 8530, VAX 8550, 

VAX 8700, VAX 8800 


Multiplexer 

Lines Vector 

Requirement 

Maximum 

Per Bl 

Maximum 

Recommended 

DMB32 

8 4 

2 

4 (VAX 85xx) 

8 (VAX 8700,8800) 


1* Limited by bus loading requirements of UNIBUS 
2* Limited by vector requirements 


The characteristics of the application software and the system loading may impose constraints on aggregate throughput. 
Assuming that the processor is only being used for terminal handling from a user program and that all active terminal 
lines are contained on the minimum number of controllers, the aggregate terminal throughput is up to 35K characters 
per second on VAX-11/730 (using a DMF32). 


PREREQUISITE SOFTWARE 

None 

OPTIONAL SOFTWARE 

Refer to the VAX/VMS System Software Order Table 
(SPD 28.98.xx) for additional information concerning pro¬ 
cessor support and license availably for layered prod¬ 
ucts. 

SOFTWARE WARRANTY 

Warranty for this software product is provided by 
DIGITAL with the purchase of a license for the product 
as defined in the Software Warranty Addendum of this 
SPD. 

INSTALLATION 

Only experienced customers should attempt installation 
of this product. DIGITAL recommends that all other cus¬ 
tomers purchase DIGITAL Installation Services which 
provide for the installation of the software product by an 
experienced DIGITAL Software Specialist. 

ORDERING INFORMATION 

Single-Use licensed software is furnished under the li¬ 
censing provisions of DIGITAL’S Standard Terms and 


Conditions of Sale, which provide, in part, that the soft¬ 
ware and any part thereof may be used on only the 
single CPU on which the software is first installed, and 
may be copied, in whole or in part (with the proper 
inclusion of DIGITAL’S copyright notice and any propri¬ 
etary notices on the software) for use on that same CPU. 

You will need a separate license for each CPU on which 
you will be using the software product (except as other¬ 
wise specified by DIGITAL). Then, Materials and Service 
Options are selected to utilize the product effectively. 

THE LICENSE OPTIONS ARE DESCRIBED BELOW. IF 
YOU ARE NOT FAMILIAR WITH THE SERVICE OP¬ 
TIONS, YOU MAY OBTAIN THE APPROPRIATE SOFT¬ 
WARE PRODUCT SERVICE DESCRIPTION(S) FROM 
YOUR LOCAL DIGITAL OFFICE. If you are already 
familiar with these options, you may obtain the ordering 
information directly from the Software Options Charts. 

LICENSE OPTIONS 
Single-Use License Option 

The Single-Use License is your right to use the software 
product on a single CPU. 

For your first installation of this software product you 
must purchase as a minimum: 
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• Single-Use License Option, and 

• Distribution and Documentation Option 

The license gives you the right to use the software on a 
single CPU and the Distribution and Documentation Op¬ 
tion provides the machine-readable software and related 
documentation. 

To use this software product on additional CPUs, you 
must purchase for each CPU as a minimum: 

• Single-Use License Option 

In addition to the right to use, the license gives you the 
one-time right to copy the software from your original 
CPU installation to the additional CPU. Therefore, the 
Distribution and Documentation Option is not required, 
but optional. 

Note: the VMS license also licenses "execute only” 
images created with the System Building Utility in VAX 
LISP/VMS. 

Distribution and Documentation Option 

The Distribution and Documentation Option provides the 
machine-readable software and the basic documenta¬ 
tion. You must have, or order, a Single-Use License to 
obtain this option. You will need this option to install the 
software for the first time. When revised versions of this 
software product become available, they may also be 
obtained by purchasing this option again. 

Software Revision Rlght-To-Copy Option 

The Right-To-Copy Option allows a customer with multi¬ 
ple CPUs to copy a revised version of a software product 
from one CPU to another. Each CPU must be licensed 
for that product. You first install the revised software on 
one CPU; then you can make copies for additional CPUs 
by purchasing the Right-To-Copy Option for each addi¬ 
tional CPU. 

Documentation-Only Option 

The Documentation-Only Option provides one copy of 
the basic documentation. 


SPD 25.01.28 

Software Product Services 

A variety of service options are available. For more 
information on these or other services, please contact 
your local DIGITAL office. 

SOURCE MATERIALS OPTIONS 

You can obtain optional source materials for this soft¬ 
ware product by signing DIGITAL’S Software Program 
Sources License Agreement and then purchasing the 
source option(s) you want. The agreement entitles you to 
use the source materials at one customer facility or 
location which is specified in the agreement. 

Most users do not require source materials. They are 
used primarily to make modifications to the software 
product. Source kits provided by DIGITAL do not neces¬ 
sarily contain all source files used by DIGITAL to build 
binary kits. 

Source License and Sources Distribution Option 

This option provides you with the machine-readable 
source code for this software product. It gives you the 
right to use the source code on any CPU at the 
facility/location specified in the agreement which has a 
Single-Use License for the object code. 

Source License and Sources Listings Option 

This option provides you with the Assembler/Compiler 
Output Listings on microfiche for this software product. It 
gives you the right to use the listings for any CPU at the 
facility/location specified in the agreement which has a 
Single-Use License for the object code. 

Sources Update Distribution Option 

This option provides you with the revised version of the 
machine-readable source code for this software product. 
You must have purchased the Source License and 
Source Distribution Option to obtain this option. 
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SOFTWARE OPTIONS CHARTS 


The distribution Media Codes used in the Software Options Chart are described below. You specify the desired Media 
Code at the end of the Order Number, e.g., QC001-HH = binaries on RL02 disk cartridge. 


4 = RC25 Disk Cartridge 

G = TU58 DECtape II Cartridge 
H = RL02 Disk Cartridge 
J = RA60 Disk Cartridge 
M = 9-track 1600 BPI Magtape (PE) 


R = Microfiche 

V = RK07 Disk Cartridge 

Y = RX01 Floppy Diskette 

Z = No hardware dependency 


Chart I 


NOTE: The availability of these software product options and services may vary by country. Customers should 
contact their local DIGITAL office for information on availability. 


OPTIONS 

ORDER 
NUMBER 
VAX-11/725 
VAX-11/730 
SYSTEMS 

ORDER 
NUMBER 
VAX-11/750 
SYSTEMS 

ORDER 
NUMBER 
VAX-11/780 
VAX-11/782* 
VAX-11/785 
SYSTEMS 

LICENSE OPTIONS: A LICENSE IS RE¬ 
QUIRED FOR EACH CPU. 




Single-Use License 

QC001-UZ 

QD001-UZ 

QE001-UZ 

MATERIALS AND SERVICE OPTIONS: 




Start-Up Service Package, Level III 

QC001-B4 

QC001-BH 

QC001-BJ 

QC001-BM 

QD001-BH 

QD001-BM 

QD001-BJ 

QD001-BV 

QE001-BM 

QE001-BJ 

QE001-BV 

Start-Up Service Package, Level II 

QC001-74 

QC001-7H 

QC001-7J 

QC001-7M 

QD001-7H 

QD001-7M 

QD001-7J 

QD001-7V 

QE001-7M 

QE001-7J 

QE001-7V 

Start-Up Service Package, Level 1 

QC001-54 

QC001-5H 

QC001-5J 

QC001-5M 

QD001-5H 
QD001-5M 
QD001-5J 
QD001-5V 

QE001-5M 

QE001-5J 

QE001-5V 

Distribution and Documentation Option 

QC001-H4 
QC001-HH 
QC001 -HJ 
QC001-HM 

QD001-HH 

QD001-HM 

QD001-HJ 

QD001-HV 

QE001-HM 

QE001-HJ 

QE001-HV 

Software Revision Right-To-Copy Option 

QC001-HZ 

QD001-HZ 

QE001-HZ 

Documentation-Only Option 

QL001 -GZ 

QL001-GZ 

QL001-GZ 

Installation Service Option 

QC001-I4 

QC001-IH 

QC001-IJ 

QC001-IM 

QD001-IH 

QD001-IM 

QD001-IJ 

QD001-IV 

QE001-IM 

QE001-IJ 

QE001-IV 

DECsupport Service 

QC001-94 

QC001-9H 

QC001-9J 

QC001-9M 

QD001-9H 

QD001-9M 

QD001-9J 

QD001-9V 

QE001-9M 

QE001-9J 

QE001-9V 
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OPTIONS 

ORDER 
NUMBER 
VAX-11/725 
VAX-11/730 
SYSTEMS 

ORDER 
NUMBER 
VAX-11/750 
SYSTEMS 

ORDER 
NUMBER 
VAX-11/780 
VAX-11/782* 
VAX-11/785 
SYSTEMS 

Basic Service 

QC001 -84 
QC001-8H 
QC001-8J 
QC001-8M 

QD001-8H 
QD001-8M 
QD001-8J 
QD001-8V 

QE001-8M 

QE001-8J 

QE001-8V 

Self-Maintenance Service 

QC001 -34 
QC001-3H 
QC001-3J 
QC001-3M 

QD001-3H 

QD001-3M 

QD001-3J 

QD001-3V 

QE001-3M 

QE001-3J 

QE001-3V 

SOURCE MATERIALS OPTIONS: 




Source License and Source Distribution Option 

QL001-EM 

QL001-EM 

QL001-EM 

Source License and Source Listings Option 

QL001-FR 

QL001-FR 

QL001-FR 

Sources Distribution Option 

QL001-NM 

QL001-NM 

QL001-NM 


*For software licensing purposes, a VAX-11/782 is a multi-processor that is considered a single CPU. 


Chart II 


NOTE: The availability of these software product options and services may vary by country. Customers should 
contact their local DIGITAL office for information on availability. 


OPTIONS 

ORDER 

NUMBER 

VAX 8200 
SYSTEMS 

ORDER 

NUMBER 

VAX 8300 
SYSTEMS 

ORDER 

NUMBER 

VAX 8500 
SYSTEMS 

LICENSE OPTIONS: A LICENSE IS RE¬ 
QUIRED FOR EACH CPU. 




Single-Use License 

Q5001-UZ 

Q7001-UZ 

Q9001-UZ 

Periodic Payment License 

Q5001-1P 

Q5001-JP 

Q7001-1P 

Q7001-JP 

Q9001-1P 

Q9001-JP 

MATERIALS AND SERVICE OPTIONS: 




Start-Up Service Package, Level III 

Q5001-BJ 

Q5001-BM 

Q7001-BJ 

Q7001-BM 

Q9001-BM 

Start-Up Service Package, Level II 

Q5001-7J 

Q5001-7M 

Q7001-7J 

Q7001-7M 

Q7001-7M 

Start-Up Service Package, Level 1 

Q5001-5J 
Q5001-5M 

Q7001-5J 

Q7001-5M 

Q9001-5M 

Distribution and Documentation Option 

Q5001 -HJ 
Q5001 -HM 

Q7001-HJ 

Q7001-HM 

Q9001-HM 

Software Revision Right-To-Copy Option 

Q5001-HZ 

Q7001-HZ 

Q9001-HZ 

Documentation-Only Option 

QL001-GZ 

QL001-GZ 

QL001-GZ 
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OPTIONS 

ORDER 

NUMBER 

VAX 8200 
SYSTEMS 

ORDER 

NUMBER 

VAX 8300 
SYSTEMS 

ORDER 

NUMBER 

VAX 8500 
SYSTEMS 

Installation Service Option 

Q5001-IJ 

Q5001-IM 

Q7001-IJ 

Q7001-IM 

Q9001-IM 

DECsupport Service 

Q5001-9J 

Q5001-9M 

Q7001-9J 

Q7001-9M 

Q9001-9M 

Basic Service 

Q5001-8J 

Q5001-8M 

Q7001-8J 

Q7001-8M 

Q9001-8M 

Self-Maintenance Service 

Q5001-3J 
Q5001-3M 

Q7001-3J 

Q7001-3M 

Q9001-3M 

SOURCE MATERIALS OPTIONS: 




Source License and Source Distribution Option 

QL001-EM 

QL001-EM 

QL001-EM 

Source License and Source Listings Option 

QL001-FR 

QL001-FR 

QL001-FR 

Sources Distribution Option 

QL001-NM 

QL001-NM 

QL001-NM 


Chart III 



NOTE: The availability of these software product options and services may vary by country. Customers should 
contact their local DIGITAL office for information on availability. 


OPTIONS 

ORDER 

NUMBER 

VAX 8600 
VAX 8650 
SYSTEMS 

ORDER 

NUMBER 

VAX 8700 
VAX 8550 
SYSTEMS 

ORDER 

NUMBER 

VAX 8800 
SYSTEMS 

LICENSE OPTIONS: A LICENSE IS RE¬ 
QUIRED FOR EACH CPU. 




Single-Use License 

QK001-UZ 

Q2001-UZ 

QM001-UZ 

Periodic Payment License 

QK001-1P 

QK001-JP 

Q2001-1P 

Q2001-JP 

QM001-1P 

QM001-JP 

MATERIALS AND SERVICE OPTIONS: 




Start-Up Service Package, Level III 

QK001-BM 

Q2001-BM 

QM001-BM 

Start-Up Service Package, Level II 

QK001-7M 

Q2001-7M 

QM001-7M 

Start-Up Service Package, Level 1 

QK001-5M 

Q2001-5M 

QM001-5M 

Distribution and Documentation Option 

QK001-HM 

Q2001-HM 

QM001-HM 

Software Revision Right-To-Copy Option 

QK001-HZ 

Q2001-HZ 

QM001-HZ 

Documentation-Only Option 

QL001-GZ 

QL001 -GZ 

QL001-GZ 

Installation Service Option 

QK001-IM 

Q2001-IM 

QM001-IM 

DECsupport Service 

QK001-9M 

Q2001-9M 

QM001-9M 
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OPTIONS 

ORDER 

NUMBER 

VAX 8600 

VAX 8650 
SYSTEMS 

ORDER 

NUMBER 

VAX 8700 

VAX 8550 
SYSTEMS 

ORDER 

NUMBER 

VAX 8800 
SYSTEMS 

Basic Service 

QK001-8M 

Q2001-8M 

QM001-8M 

Self-Maintenance Service 

QK001-3M 

Q2001-3M 

QM001-3M 

SOURCE MATERIALS OPTIONS: 




Source License and Source Distribution Option 

QL001-EM 

QL001-EM 

QL001-EM 

Source License and Source Listings Option 

QL001-FR 

QL001-FR 

QL001-FR 

Sources Distribution Option 

QL001-NM 

QL001-NM 

QL001-NM 
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